Historically, when businesses have communicated with clients it has been possible to establish protocols that govern the situations in which one member of staff is permitted to communicate with a client. For example, a bank may establish an internal protocol that mandates that specialist members of staff can only communicate with a client on a particular matter after the client has raised that matter with their relationship manager at the bank and the bank has introduced the client to the specialist. Protocols of this sort have limitations in a world of modern communications. First, it is difficult to ensure compliance. It is not impossible for the specialist to contact the client directly without having been introduced by the relationship manager. Second, even if staff at the business observe the protocol it is not practical to bar the client from contacting a particular person, so the protocol does not ensure that the client manager is involved in all communications. Third, such a protocol is not readily applicable to the problems that arise in conventional digital communications systems. This will be discussed in more detail below, but in general it can be noted that increasing reliance on technology tends to bring an increasing reliance on automatic measures to prevent policies being breached.
Conventional mechanisms by which members of staff at a business may communicate with clients include telephone and email. Telephone has the disadvantages that it requires specific infrastructure to ensure that all calls are recorded for regulatory purposes, that it takes time to coordinate and run calls especially when recorded lines are involved, and that in any event there are often times when people are occupied on other matters and cannot communicate conveniently by phone. Email has the disadvantage that it is inconvenient to ensure encryption and authentication. Some organisations have developed custom web-based portals through which advisors can communicate securely with clients. However, these are inconvenient for clients to use.
Outside the field of business, instant messaging (IM) or chat platforms have become popular, particularly with the advent of mobile technology. IM is conventionally supported by a client application running on a user device, for example a smartphone or a computer terminal. The client application presents a user interface from which a user can generate messages for transmission to other users, and view messages received from other users. When a message is to be transmitted the client application can cause the user device to transmit that message to one or more remote servers operated by the organisation that provides the IM platform in question. Those servers then direct the message to the client application of the intended recipient. IM messages are typically transmitted over internet protocols.
Typically, a user communicates via IM by first logging into an IM account by means of the IM client application. Once logged in, the user can see which of his/her contacts are also logged in. This information is derived from the servers of the IM provider or by leveraging the contacts known to the client on their device in some cases. The user can communicate with one more of those users. Some IM clients allow the user also to transmit messages to contacts not currently logged into their account, who can then view the messages once they are logged in. One particular feature of IM is that the IM messages pass via a dedicated back-end operated by the organisation that provides the IM platform in question.
Once one or more messages have been exchanged between two participants in an IM system that session can be continued by the exchange of further messages as a chat session. All messages between a pair of users can be treated as part of a single chat session. Alternatively, a chat session may be given a title or other identifier, and messages may be assigned to a particular chat session, for example to distinguish the chat sessions by subject matter.
In many conventional IT systems, permissions can be set to govern the actions that users may take. Typically, individual users are assigned to groups, and permissions are assigned to those groups. For example, users who have been assigned to a “compliance” group may be permitted to see all communications between a business's staff and its clients, whereas users assigned to a “specialists” group may be barred from communication with clients by default. This approach makes it relatively straightforward to manage and police standard permissions in a large organisation. However, this approach is unsuitable for providing an optimum set of relationships in a business with complex client requirements. For example, a specialist may be ordinarily barred from communicating directly with clients, but it may be desired for that specialist to communicate with a client after having been introduced by a relationship manger. This would mean assigning individual permissions to that specialist that differ from his or her normal group permissions. Typically, setting up individual permissions is complicated to implement and difficult to police because once individual rights have been given to many different users it becomes difficult to supervise all the permissions to ensure that they remain correctly limited. Furthermore, in any conventional communications system it is difficult or impossible to establish permissions that are individualised to a particular matter.
There is a need for an improved communication system.